Stripe API Design Evaluation and Latency Budget
Learn how Stripe API meets different non-functional requirements.
As we have seen, Stripe plays an important role in the payment ecosystem and makes the payment process smooth via the API endpoints we provided in the previous lesson. While we achieved different functional requirements through these endpoints, we still have to focus on the non-functional requirements we identified in the initial lesson. This lesson will describe how we achieve the non-functional requirements and different optimization strategies to improve the efficiency and response time of our service. Toward the end, we will also compute the response time of the Stripe API.
Non-functional requirements#
The following section discusses how Stripe API meets the non-functional requirements.
Strong consistency#
Due to the nature of the API that involves operations on critical data and financial data, strong consistency is paramount for the Stripe API. The Stripe API is strongly consistent and provides consistent data at every level by adopting the following measures:
Exactly once semantics: Idempotency keys are used in the API call where the non-idempotent method needs to be used, such as the
POSTHTTP method. This way, we avoid multiple operations where only one operation needs to be performed.Reconciliation: The internal system's services periodically communicate with each other to compare their statuses to confirm that they are in agreement. According to some studies, this is the last line of defense in the payment system. Reconciliation not only improves the security of the payment system but also makes the system internally consistent.
Point to Ponder
Question
Why is reconciliation in the payment system considered the last line of defense?
The reconciliation ensures that the payment owed and due match the transactions that have been completed. In case of transaction ambiguities, it is considered that either the system security is compromised or any other fraudulent activity has occurred. An example where reconciliation would help is given below:
Assume a customer buys some goods and pays via their credit card. Ultimately, the bill provided to the customer has a different amount and date from what is present in Stripe records. Such discrepancies can be detected via the reconciliation process by comparing the records in Stripe and the bill provided to the customer.
Security#
To ensure secure communication and data transfer, we use a number of techniques. Firstly, we use the HSTS (HTTP strict transport security) mechanism to avoid man-in-the-middle attacks and ensure that the applications or browsers use HTTP protocol over TLS to comply with PCI standards. Secondly, the credit or debit card numbers are encrypted with advanced encryption algorithms such as AES-256 during storage (or in transit). Similarly, a session is created with Stripe to process the payment securely when a user aims to pay for a product.
Note: Stripe uses a number of machine learning systems known as radars that use hundreds of signals and heuristics to detect and prevent fraud.
Reliability#
Data is replicated along multiple databases to increase reliability and durability. For this purpose, we use a mix of SQL and NoSQL databases for storing various types of data. We need an SQL database for storing customers' and accounts' data, while for unstructured data such as invoices, transactions, and charges, we use a NoSQL database. NoSQL database not only provides reliability but also aids in high availability and increased performance for unstructured data, which makes it an ideal choice for Stripe. Similarly, we replicate data across multiple regions and take regular snapshots to prevent data loss.
Availability#
To increase the system's availability, we adopt proper rate limiting, monitoring, and automated recovery mechanisms. Apart from increasing the system's availability, we also ensure strong consistency because of its significance in the payment ecosystem. However, there may often be a trade-off between availability and performance, on the one hand, and consistency, on the other, depending on the nature of the current use case.
Scalability#
The scalability of API can be increased by adding more capacity to the infrastructure to handle a large number of businesses and customer requests. Although the Stripe service also depends on other services (for example, cards networks) to scale effectively, here we only focus on the scalability of Stripe and assume that the other supporting services are scalable. Scaling other supporting services has monetary benefits for the providers. These monetary benefits are incentives for high scalability and high availability.
Achieving Non-Functional Requirements
Non-Functional Requirements | Approaches |
Strong consistency |
|
Security |
|
Reliability |
|
Availability |
|
Scalability |
|
Latency budget#
Let's calculate the message size before moving toward latency and processing time.
As discussed in the back-of-the-envelope latency calculations, the latency of the
GETandPOSTrequests are affected by two different parameters. In the case ofGET, the averageremains the same regardless of the data size (due to the small request size), and the time to download the response varies by per KB. Similarly, for POSTrequests, thetime changes with the data size by per KB from the base RTT time, which was 260 ms.
Message size#
As in the previous lesson, we discussed some selective endpoints of different services due to their repetitive nature. This applies to estimating the sizes of GET or POST methods as well. All the GET or POST requests carry approximately equal sizes. Therefore, we only consider the request to retrieve or create an invoice to estimate the size. The GET request to retrieve the invoice only contains the invoice ID; therefore, its size is considered up to 1 KB. However, the responses of any request contain all the parameters relevant to an invoice; therefore, we assume their sizes will not exceed 5 KB. Each request and response size is given below:
GETrequest size to retrieve an invoice: In theGETrequest, we only pass the invoice ID in as a query parameter; therefore, we consider the whole request size to be around. GETresponse size to retrieve an invoice: The response to retrieve an invoice contains several parameters (no more than 30); therefore, its size will not be more than. POSTrequest size to create an invoice: The request contains approximately the same parameters as in theGETresponse; consequently, we consider its size to be. POSTresponse size to create an invoice: Since we would receive the same parameters in the response as the one we pass in the request, the response size will also remain up to.
Response time#
The following calculator computes the minimum and maximum response time of the GET method:
Response Time Calculator to Retrieve an Invoice
| Enter the size in KBs | 5 | KB |
| Minimum latency | f192.5 | ms |
| Maximum latency | f273.5 | ms |
| Minimum response time | f196.5 | ms |
| Maximum response time | f277.5 | ms |
Assuming the response size is 5 KB, then the latency is calculated by:
Similarly, the response time is calculated using the following equation:
Now, for minimum response time, we use minimum values of base time and processing time:
Now, for maximum response time, we use maximum values of base time and processing time:
For the POST request to create an invoice, we consider the minimum and maximum response times for both the request and response of the POST method in the following calculator:
Response Time Calculator to Create an Invoice
| Enter the size in KBs | 5 | KB |
| Minimum latency | f386.65 | ms |
| Maximum latency | f467.65 | ms |
| Minimum response time | f390.65 | ms |
| Maximum response time | f471.65 | ms |
Assuming the request size is 5 KB:
Similarly, the response time is calculated as:
We have calculated the maximum response times for the GET and POST requests, which are,
Note: The API response size we calculated earlier is purely based on the interaction with Stripe services. We have seen that Stripe acts as a payment gateway in the payment ecosystem. Therefore, information and payment processing flow through many entities involved in the ecosystem, which affects the processing time of our API. For example, verification of customer information, such as credit or debit card information and the validity of their account in the issuing bank, may have an impact on the processing time. In light of this, the successful payment may take time, ranging from several seconds to several days.
In this chapter, we designed an API for Stripe (payment gateway). The Stripe API has a complex nature that involves various operations and services to be implemented carefully to meet the needs of a wide range of users and businesses across the globe. Similarly, identifying endpoints and micro-services requires rigorous attention to meet different functional requirements, and the communication between different organizations (entities) needs to be PCI compliant. Designing Stripe API also involves careful consideration and implementation of various non-functional requirements, such as consistency, security, reliability, availability, and scalability.
Stripe Interaction with Cards Network
Requirements of the Twitter API